Please, no multiple inheritance. And avoid inheritance as much as possible. Go with composition unless there is an extremely compelling case.

I think it's a well-known mixin pattern?
/cc @jgsogo
suggestion on how to to it better are welcomed

@memsharded do you want me to implement AppleSystemBlock like it was done in CMakeToolchain?
https://github.com/conan-io/conan/blob/develop/conan/tools/cmake/toolchain.py#L280

Yes, please, avoid inheritance and mixins unless it is strictly necessary. Composition scales better and is more flexible for user customization. Going with a "blocks" approach like the CMakeToolchain will be better, please go that way.

I am looking at how to implement blocks similarly to how it was done in CMake toolchain.
there are several ideas, and I think I'll need some advice.
first off, there are two main things Apple block should define:

• compiler executables, c (known as CC in autotools world) and cpp (known as CXX)
• flags for compilers and linkers, like c_args (CFLAGS), cpp_args (CXXFLAGS), link_args (LDFLAGS), etc.

for executables, it should take the very least priority (only use when not explicitly defined), for variables, it should effectively append them to any existing.

then, unlike CMake, meson machine files are simple .ini files with very limited syntax. they are not turing-complete, and cannot contain conditions, loop, and other flow control instructions. there are very few operators supported, like + and / (https://mesonbuild.com/Machine-files.html#constants), but that's it.

on the other hand, there is an interesting feature that meson supports multiple cross-files overriding each other: https://mesonbuild.com/Machine-files.html#loading-multiple-machine-files

so, we may use something like --cross-file conan_meson_cross_apple.ini --cross-file conan_meson_cross_main.ini.

therefore, there are likely 3 major approaches on how to implement that:

1. use multiple cross-files overriding each other
2. use a single cross-file with several blocks
3. use a single cross-file with one block, but compose several contexts within the toolchain

1. is easy to implement, but it might be kinda misleading: too many files to deal with for the consumer, e.g. too long command lines, and easy to mess up with an order
2. might be tricky with a limited .ini syntax. e.g. I can't define the same value twice within the same machine file, I will get an error:

configparser.DuplicateOptionError
option 'buildtype' in section 'built-in options' already exists

and I can't check if it's already defined above, without using an external check in the code.

3. is also easy to implement, it will be just a matter of creating several context dictionaries and merging them according to our specific rules (executables override, flags append). but it's not really a blocks approach.

looking for the advice, thanks!

Better move XCRun first to modern approach. It should be less detection based and more configuration based.

the XCRun is already imported from a new namespace conan.tools.apple or what exactly do you mean?

anyway, I think improvements of XCRun, if any, could be done in another, their own PR. this is outside of the scope of this PR IMO.

The idea is that generators like this one do not auto-detect anything. XCRun is deducing things by executing some commands right? That should be moved to input configuration, like the new [conf].

This is a general effort we are doing in 2.0, we are removing all the platform, architecture, compiler, env-vars detection in generators and helpers, and that should happen in the input configuration. Please try that approach better.

I don't know right now how it should look like and how it should be implemented.
if you have some example, I can take a look, but my point it belongs to XCRun, not to the meson toolchain.
in other words, as I understand, XCRun will have some code to read conf file instead of executing commands.
I don't see any reason why it should be done inside this particular PR - it is just using XCRun, and for meson toolchain it's an implementation detail how exactly it is implemented under the hood.
I also don't understand how is it going to work in CI, e.g. in case of ConanCenter, e.g. who, when and how exactly should populate conf with the input configutation?
really, I am just relying on the existing implementations of conan.tools namespace here, if they are somehow bbad/buggy or don't meet the conan 2.0 requirements, let's create an another issue and improve in another PR.